1. Technical Field
This invention relates generally to providing directory services in a distributed computing environment.
2. Description of the Related Art
A directory service is the central point where network services, security services and applications can form an integrated distributed computing environment. Typical uses of a directory services may be classified into several categories. A xe2x80x9cnaming servicexe2x80x9d (e.g., DNS and DCE Cell Directory Service (CDS)) uses the directory as a source to locate an Internet host address or the location of a given server. A xe2x80x9cuser registryxe2x80x9d (e.g., Novell NDS) stores information about users in a system composed of a number of interconnected machines. The central repository of user information enables a system administrator to administer the distributed system as a single system image. Still another directory service is a xe2x80x9cwhite pagesxe2x80x9d lookup provided by some e-mail clients, e.g., Netscape Communicator, Lotus Notes, Endora and the like).
With more and more applications and system services demanding a central information repository, the next generation directory service will need to provide system administrators with a data repository that can significantly ease administrative burdens. In addition, the future directory service must also provide end users with a rich information data warehouse that allows them to access department or company employee data, as well as resource information, such as name and location of printers, copy machines, and other environment resources. In the Internet/intranet environment, it will be required to provide user access to such information in a secure manner.
To this end, the Lightweight Directory Access Protocol (LDAP) has emerged as an IETF open standard to provide directory services to applications ranging from e-mail systems to distributed system management tools. LDAP is an evolving protocol that is based on a client-server model in which a client makes a TCP/IP connection to an LDAP server, sends requests, and receives responses. The LDAP information model in particular is based on an xe2x80x9centry,xe2x80x9d which contains information about some object. Entries are typically organized in a specified tree structure, and each entry is composed of attributes.
LDAP provides a number of known functions including query (search and compare), update, authentication and others. The search and compare operations are used to retrieve information from the database. For the search function, the criteria of the search is specified in a search filter. The search filter typically is a Boolean expression that consists of qualifiers including attribute name, attribute value and Boolean operators like AND, OR and NOT. Users can use the filter to perform complex search operations. One filter syntax is defined in RFC 2254.
LDAP thus provides the capability for directory information to be efficiently queried or updated. It offers a rich set of searching capabilities with which users can put together complex queries to get desired information from a backing store. Increasingly, it has become desirable to use a relational database for storing LDAP directory data. Representative database implementations include DB/2, Oracle, Sybase, Informix and the like. As is well known, Structured Query Language (SQL) is the standard language used to access such databases.
Many security systems are moving their databases to LDAP with the expectation that they can share common attributes, such as unique identifiers. A unique identifier is an identifier code (e.g., a number with many digits) that is guaranteed to be unique within the database of a security system. Unique identifiers are used to facilitate access control decisions. When an administrator adds a user or group to the security system, the security system typically generates a unique identifier or verifies that a unique identifier supplied by the administrator is unique, stores the unique identifier in the security system database, and protects the unique identifier so that it can never be modified.
LDAP, however, does not provide any mechanism to generate, verify, and protect a unique identifier. Therefore, each security system must store its own set of unique identifiers on LDAP, protect these unique identifiers so they cannot be modified, and take elaborate precautions to ensure that LDAP users do not attempt to fool the system by creating their own unique identifier information. The present invention overcomes this deficiency of the prior art.
The present invention defines a trusted process for use with a hierarchical directory service such as LDAP for enabling different security systems to store and retrieve unique identifiers that are shared or common to the entire directory. The trusted process allows LDAP users to store and to retrieve unique identifiers on LDAP using standard LDAP interfaces. It also allows security systems to share unique identifier information. The trusted process generates or verifies a unique identifier, guarantees the uniqueness of a unique identifier within the entire directory (rather than just within a single security system), and guarantees that any unique identifier returned to an LDAP user is a trusted unique identifier.
According to one aspect of the invention, a computer-implemented method is provided for configuring a unique identifier that may be shared by a plurality of users of a hierarchical directory such as LDAP. The method begins by intercepting a call from the LDAP administrator to a unique identifier attribute. The method then verifies that any unique identifier specified in the call is unique to the directory. If the call does not include a unique identifier, one is generated. Upon verification or generation of the unique identifier, as the case may be, the unique identifier is stored in a trusted unique identifier attribute of an entry of an object class in the directory. An access control is then set on the entry so that it cannot be modified. Although the unique identifier is actually stored in the trusted unique identifier attribute, the users of the unique identifier are notified that the unique identifier can be retrieved by making LDAP calls to the unique identifier attribute.
According to another aspect of the invention, a computer-implemented method is also provided for managing calls to the unique identifier attribute. When such calls are made, they are intercepted and then processed to retrieve the unique identifier from the trusted unique identifier attribute. In particular, the routine first verifies that a trusted process created an entry of a given object class that contains the trusted unique identifier attribute. Upon verification, the unique identifier is retrieved from the trusted unique identifier attribute (as opposed to the unique identifier attribute) and returned to the calling entity.
The present invention may be implemented in a computer program product useable in an LDAP directory service. The product comprises object class that contains a trusted unique identifier attribute used to store a unique identifier, and a trusted process. The trusted process includes code for creating a child entry of the object class, code for storing the unique identifier in the trusted unique identifier attribute, code for setting an access control on the child entry so that the child entry cannot be modified, and code for intercepting calls to a unique identifier attribute and processing such calls using the trusted unique identifier attribute.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects and features should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the preferred embodiment.